home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20041116-20060924 / 000333_rock_spambust_violin@yahoo.com_Fri May 5 10:48:18 2006.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Path: newsmaster.cc.columbia.edu!newsfeed.nyu.edu!news.maxwell.syr.edu!postnews.google.com!v46g2000cwv.googlegroups.com!not-for-mail
  2. From: "tomviolin" <rock_spambust_violin@yahoo.com>
  3. Newsgroups: comp.protocols.kermit.misc
  4. Subject: using FILE OPEN quadruples memory usage!
  5. Date: 4 May 2006 15:53:51 -0700
  6. Organization: http://groups.google.com
  7. Lines: 68
  8. Message-ID: <1146783231.532130.44080@v46g2000cwv.googlegroups.com>
  9. NNTP-Posting-Host: 129.89.149.244
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset="iso-8859-1"
  12. X-Trace: posting.google.com 1146783236 7588 127.0.0.1 (4 May 2006 22:53:56 GMT)
  13. X-Complaints-To: groups-abuse@google.com
  14. NNTP-Posting-Date: Thu, 4 May 2006 22:53:56 +0000 (UTC)
  15. User-Agent: G2/0.2
  16. X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3,gzip(gfe),gzip(gfe)
  17. Complaints-To: groups-abuse@google.com
  18. Injection-Info: v46g2000cwv.googlegroups.com; posting-host=129.89.149.244;
  19.    posting-account=ornCOQwAAAAyCG4a7NOAj_SMr54FiqNu
  20. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:15589
  21.  
  22. I have discovered that using FILE OPEN in C-Kermit 8.0.211 causes
  23. Kermit's memory usage to quadruple.  The memory usage does not go back
  24. down after the file(s) are closed, either.
  25.  
  26. This memory explosion does NOT appear to occur when the "old" OPEN FILE
  27. method is used, only with the "new" FILE OPEN method.  So it is
  28. possible to work around it, albeit inconveniently at times.
  29.  
  30. Further openings of files do not appear to result in further memory
  31. expansion.  I was able to have multiple files open using FILE OPEN and
  32. it did not proceed to octuple memory usage, for example.
  33.  
  34. I'm using Kermit compiled for ARM with "make linuxnc KFLAGS=-DNOBIGBUF"
  35. (I'm trying to save memory!)  and running on a 32M embedded board
  36. running the Linux 2.4.26-ts9 kernel.
  37.  
  38. How can this be happening if FILE OPEN is simply a front-end for the
  39. fopen() system call?  I could see memory on the order of kilobytes
  40. being allocated, but we're talking several megabytes of memory being
  41. consumed here, just from opening a text file.
  42.  
  43. Is there perhaps some Makefile option (along the lines of the
  44. -DNOBIGBUF that I already used) that can mitigate this?
  45.  
  46. Witness the following test: session one is a Kermit session, and
  47. session 2 is showing the results of ps v -p performed on the Kermit
  48. process at each step.
  49.  
  50. --- session one ---
  51. $ kermit
  52. C-Kermit 8.0.211, 10 Apr 2004, for Linux
  53.  Copyright (C) 1985, 2004,
  54.   Trustees of Columbia University in the City of New York.
  55. Type ? or HELP for help.
  56. (/home/dlogger/) C-Kermit>echo \v(pid)
  57. 29009
  58. (/home/dlogger/) C-Kermit>
  59.  
  60. -- session two --
  61. $ ps v -p 29009
  62.   PID TTY      STAT   TIME  MAJFL   TRS   DRS  RSS %MEM COMMAND
  63. 29009 pts/1    S      0:00    247  1666  2849 1308  4.5 kermit
  64. $
  65.  
  66. -- session one --
  67. (/home/dlogger/) C-Kermit>file open \%f .profile
  68. (/home/dlogger/) C-Kermit>
  69.  
  70. -- session two --
  71. $ ps v -p 29009
  72.   PID TTY      STAT   TIME  MAJFL   TRS   DRS  RSS %MEM COMMAND
  73. 29009 pts/1    S      0:00    265  1666  6905 5452 18.9 kermit
  74. $
  75.  
  76. -- session one --
  77. (/home/dlogger/) C-Kermit>file close all
  78. (/home/dlogger/) C-Kermit>
  79.  
  80. -- session two --
  81. $ ps v -p 29009
  82.   PID TTY      STAT   TIME  MAJFL   TRS   DRS  RSS %MEM COMMAND
  83. 29009 pts/1    S      0:00    267  1666  6905 5460 19.0 kermit
  84. $
  85. --- end of sessions ---
  86.  
  87. Note that the memory usage actually went UP even further after the file
  88. was closed!
  89.